The distribution of a single program, so that a portion of the program executes on more than one computer has become more pervasive as "desktop" computers become more powerful. FIG. 1 demonstrates an example of a computer network containing several distributed computers upon which an application can execute. While most computer networks are many orders of magnitude larger, this small network is used as an example. Presently, many computer systems allow objects to communicate over a network. In this small network an application may be distributed throughout the network such that some functions of the program execute on one computer system and other functions execute on a different computer system.
One example of such a distributed processing system is the client/server program architecture. Client/server program architectures have been developed to allow a common portion of a program to execute on one processing system (the server application) and a second portion of the program to execute on various other processing systems (the client applications). However, developing client/server applications is known to be error prone and difficult. The programmer typically must write not only the client and server programs, but also the networking code that allows the client and server to interact. In addition, the programmer must decide what function to place on the client and what to place on the server. Choosing incorrectly can degrade the performance of the application.
The development of a client/server application may be further complicated in real-world computing environments where different users employ different equipment. For example, one user might use a network computer connected to a server over a high-speed local area network. Since network computers tend to have restricted memory capacities, they can only support client programs of limited size. In contrast, a second user might be using a personal computer connected to the same server using a 28.8 kilobits/second modem. In this second case, the client has virtually unlimited memory capacity, but is connected over a slow network. Consequently, in the second case, the decision about which functions to place on the client and which to place on the server need barely take into account client limitations, but should be extremely cautious about generating network traffic. As is demonstrated by these examples, a single division of function for a distributed application may not be sufficient for all computing topologies.
A basic function which is generally necessary to provide distributed processing is to allow program objects to communicate over a network. One method of allowing objects to communicate over a network is RPC, which stands for Remote Procedure Call. RPC has existed since the mid 1980s and is further described by Birrell and Nelson in Implementing Remote Procedure Calls, ACM Transactions on Computer Systems 2, 1984, pp 39-59. Further improvements have been made to RPC, such as DSOM, or Distributed Systems Object Model, continuing into the present. In the systems of the prior art, the programmer describes the interfaces to the objects using an Interface Definition Language (IDL). The systems then provide tools that automatically transform the IDL specification into executable code.
Recently, Sun Microsystems released an object oriented programming language called Java which includes a capability similar to that of RPC and DSOM called Remote Method Invocation, or RMI. Using systems which are Java enabled, the programmer can now write a distributed object program without explicit recognition of the network upon which the program will be running. However, using this technology, the programmer or implementer is still required to write additional code that enables remote invocation of objects (or write the IDL specification).
As with many coding tasks, such as the generation of client/server applications described above, writing IDL may be error-prone because of the complexity of the division of functions and because of the numerous decisions which must be made in the design of the program which may ultimately affect its performance. For example, as with client/server applications, the optimal distribution point may vary based on computing topologies. If two computers are equally powerful, then the optimal distribution might have an equal number of objects executing on each computer; if the two computers have disparate capabilities, then the more powerful computer might execute more of the objects. Since heterogeneous computing topologies are common, code written statically using an IDL may often result in sub-optimal performance.
In addition, should it be determined that the distribution of objects is sub-optimal, the current specification is typically deleted and another written. Since choosing the optimal distribution point is a difficult task, this problem occurs often in modern programming environments.
One way of relieving the burden on programmers developing distributed function applications is through the use of program-creation tools which allow a programmer to specify a program using the tool, and indicate the object boundaries at which the objects are to be distributed. The tool then generates the executable code for the program. However, these tools generate static program partitions, and thus suffer from heterogeneity problems similar to IDL systems. In addition, tools do not typically interoperate. Thus, multiple programmers working on the same program are forced to standardize on the same tool to work effectively together. Since tools have strengths and weaknesses, standardizing on a single tool is undesirable.
In view of the above discussion, there exists a need for improvement in the development, generation and distribution of distributed processing applications, in particular, client/server applications.